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(54) Abstract Title 

Ordering system 

(57) An ordering system of a cafeteria etc., includes a cafeteria etc server provided with a menu file 1 
ingredient file 2, etc. and terminals PC for use by customers, connected by a network. Orders are placed by the 
customers by accessing the server from the terminals PC. The customers select the food they want from the 
menu based on information read from the menu file. The information concerning the food to be cooked that 
day and the quantity thereof and the ingredients which have to be ordered and the quantity thereof is 
successively updated in accordance with the orders from the customers. 
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ORDERING SYSTEM 



The present invention relates to an ordering 
system used for taking orders at a store, for example, a 
restaurant, more particularly relates to an ordering 
system suitable for a restaurant of a self-service format 
such as a company cafeteria for employees. 

Among the various types of restaurants, 
restaurants, such as employee cafeterias and student 
cafeterias, often adopt the self-service format. Not only 
these cafeterias, but also all restaurants of the self- 
service format usually arrange already cooked food on 
shelves in advance, have persons coming to eat select 
their favorite foods from the shelves, and then have them 
settle their bills at the cashier. 

In the case of such restaurants, accordingly, 
it is necessary to prepare in advance a certain quantity 
of food. Further, in order to increase the range of 
selection of the food, it is necessary to prepare a 
number of different types of food. 

Further, in other forms of restaurants, the 
food is prepared after the customer comes in and decides 
what to order. Even in this case, however, it is 
necessary to prepare for cooking the food in advance. 
Further, it is necessary to prepare several portions 
worth of food in advance in the case of food which cannot 
be prepared in single serving portions. 

Further, no matter what the form of the 
restaurant, it is necessary to order the ingredients in 
advance. It is preferable in many senses to limit the 
amount of ingredients ordered to the required least 
amount. 

Here, a general problem of restaurants is that 



it is very difficult to predict the number of customers 
who will come in on a certain day or in a certain time 
frame. When a restaurant has been run for a long number 
of years, its manager can predict the approximate number 
5 of people who will come in by the rule of thumb, but the 
exact number of guests will vary considerably due to date 
of the month, the day of the week, the weather of that 
day, holidays and events, and other conditions. Further, 
there are the individual whims of the guests - a 
10 condition making prediction quite impossible. 

Accordingly, the actual number of customers who come in 
will differ from the predicted number of customers in 
many cases. 

Prediction of the number of customers coming to 

15 the restaurant is an extremely important factor in the 
determination of the number of servings of food to 
prepare for that day and the amount of the ingredients to 
order. Such advance preparations are particularly 
necessary in the case of a restaurant of the self-service 

20 format, and thus it is difficult to appropriately adjust 
the number of servings to prepare to meet with the number 
of customers. 

While the number of servings and amount of 
ingredients ordered are determined according to the 

25 predicted number' of customers, when the predicted number 
of customers and the actual number of customers differ, 
the following problems arise in running the restaurant. 
Note that here it is assumed that the number of servings 
and the amount of ingredients ordered are determined 

30 based on the predicted number of customers. 

1) Case where the number of customers is 
larger than the predicted number 

In this case, there is an extremely high chance 
that the number of servings and the ordered ingredients 

35 will be insufficient. Where there is insufficient food, 
it becomes impossible to serve customers who arrive 
later. If this insufficient amount of food continues 



regularly, the restaurant may gain the reputation of 
being unable to provide sufficient food. 

2) Case where the number of customers is 
lower than the predicted number 
5 , In this case, there is an extremely high chance 

that the ingredients purchased and the cooked food will 
be wasted. Particularly, there are fresh foods which 
cannot be preserved and any remaining amount thereof must 
be thrown away. 

10 Further, particularly in a case of the 

restaurant of a self-service format, it is necessary for 
customers to be able to immediately obtain the food they 
desire when they arrive. For this reason, precooking is 
absolutely necessary. While it possible however to keep 

15 uncooked ingredients until the next day, such precooked 
food cannot be preserved, so it is necessary that it be 
consumed within the same day. For this reason, it is 
sometimes necessary to throw away the left over cooked 
food. 

20 Thrown away foods become a loss for the 

restaurants. The larger the amount thrown away, the 
larger the burden on the restaurant. Further, if a large 
amount of precooked food continues to be thrown away, the 
restaurant may end up with the reputation of a place . 

2 5 which wastes food. This may also cause problems with the 
general reputation of the restaurant. 

Even if the amount of surplus ingredients could 
be preserved, investment etc. in storage equipment 
becomes necessary. Further, unless the amount of 

30 ingredients ordered is kept to the required level at all 
times, considering the cost of storage etc., the 
restaurant will end up with greater expenses and loss. 
For this reason, the amount of ingredients ordered and 
the number of servings prepared in advance preferably 

35 should be kept as low as possible. 

On the other hand, it is necessary to avoid 
situations where customers coming to the restaurant 



cannot be served since this is a service industry. 
Accordingly, in this case, it becomes necessary to 
increase the amount of ingredients ordered and the number 
of servings prepared in advance by a certain percentage 
5 above the predicted levels. 

In this way, the amount of ingredients ordered 
and the number of servings prepared become very large 
problems in running a restaurant, 

10 It is desirable . . 

— to provide an ordering system 

capable of efficiently ordering ingredients and preparing 
food - 

It is also desirable to — _ 

15 provide an ordering system enabling automatic calculation 
and updating of the amount of ingredients which should be 
ordered and the quantity which should be cooked. 

Note that needless to say the effect of automatic 
calculation and updating of the quantity of goods ordered 

20 etc. or the ability to obtain a grasp in advance of the 
minimum quantity of goods which will become necessary on 
a certain day can also be applied to stores other than 
restaurants or to mail order sales, telephone shopping, 
and on-line sales, but the following explanation will be 

25 macte of the case of ^plicatdon of an efbcdiiTBTt of the presait inrenticn 
to . a cafeteria system as an example. 

In an ordering system embodying — 

the present invention, a cafeteria 

server provided with a menu file, ingredient file, etc. 

30 and terminals PC for use by customers are connected by a 
network and orders placed by the customers accessing the 
cafeteria server from the terminals PC. The customers 
select the food they want from the menu based on 
information concerning the menu of the cafeteria read 

35 from the menu file. The information concerning the food 
to be cooked that day and the quantity thereof and the 
ingredients which have to be ordered and the quantity 



thereof is successively updated in accordance with the 
orders from the customers. 

Reference will now be made, by way of example, 
to the accompanying drawings, in which: 



Fig. 1 is a view of a cafeteria system according to 
an embodiment of the present invention; 

Fig. 2 is a view of the system configuration on the 
cafeteria side; 

Fig. 3 is a view of the configuration of a menu 

file; 

Fig. 4 is a view of the configuration of an 
ingredient file; 

Fig. 5 is a view of the configuration of an order 
receiving file; 

Fig. 6 is a view of the configuration of an 
ingredient ordering file; 

Fig. 7 is a view of the configuration of a serving 

file; 

Fig. 8 is a view of the configuration of an 
individual setting file; 

Fig. 9 is a view of the configuration of a terminal; 

Fig. 10 is a block diagram of an internal 
configuration of the terminal; 

Fig. 11 is a block diagram of the internal 
configuration of a reception device/management terminal; 

Fig. 12 is a block diagram of the internal 
configuration of a counter terminal; 

Fig. 13 is a block diagram of the internal 
configuration of a kitchen terminal; 

Fig. 14 is a flow chart of a processing routine 
taking note of the operation for placing an ordering by a 
customer; 

Fig. 15 is a view of processing when issuing a 
coupon by using a printer; 



Fig. 16 is a view of the processing when writing the 
content of an ordering on a customer card; 

Figs. 17A and 17B are first parts of a flow chart of 
the processing routines on the terminal and restaurant 
5 server side when placing an order; 

Fig. 18 is a second part of a flow chart of the 
processing routines on the terminal and restaurant server 
side when placing an order; 

Fig. 19 is a view of an example of a display of an 
10 initial menu screen; 

Fig. 20 is a view of an example of the display of a 
table of a Japanese food menu; 

Fig. 21 is a view of an example of the display of a 
detailed screen of a selected menu; 
15 Fig. 22 is a view of an example of the display of an 

order form and an example of entries in it? 

Fig. 23 is a view of an example of the display of a 
confirmation screen; 

Fig. 24 is a first part of a flow chart of the 
20 processing routine in a cafeteria system when setting a 
password; 

Figs. 25A and 25B are second parts of a flow chart 
of the processing routine in the cafeteria system when 
setting a password; 
"25 Fig. 2 6 is a view of an example of the display of an 

initial screen of the password setting; 

Fig. 27 is a view of an example of the display of a 
screen of a new setting; 

Fig. 28 is a view of an example of the display of a 
30 screen for confirming the new setting; 

Fig. 29 is a first part of a view of an example of 
the display of a screen for change of a password; 

Fig. 30 is a second part of a view of an example of 
the display of a screen for change of a password; 
35 Fig. 31 is a flow chart of a processing routine 

executed on a cafeteria server side after reception of an 
order; 



Fig. 32 is a flow chart of the processing routines 
on the cafeteria server side at the time of a deadline 
and before a deadline; 

Figs. 33A and 33B are flow charts of a processing 
routine in a cafeteria system at the time of cancellation 
of an order; 

Fig. 34 is a flow chart of a processing routine when 
displaying information on a kitchen terminal; 

Fig. 35 is a view of an example of a screen 
displayed on the kitchen terminal; 

Fig. 36 is a view of an example of a display screen 
of a kitchen terminal showing information with respect to 
a certain menu; 

Fig. 37 is a view of an example of a display screen 
of a remaining number of uncooked servings; 

Fig. 3 8 is a view of an example of the display of a 
screen for checking on deliveries; 

Fig. 39 is a view of an example of a keyboard of the 
kitchen terminal; 

Fig. 40 is a flow chart of a processing routine when 
the customer comes to a cafeteria; 

Fig. 41 is a view of an example of a customer guide 
display; 

Fig. 42 is a flow chart of a processing routine when 
inspecting ingredients; and 

Fig. 43 is a view of an example of the display of a 
message when the cafeteria is full. 



An enfoodiment of a first aspect of the present 

inventioi can provide an ordering system provided with a 

cafeteria server and a terminal operated by a user of the 
cafeteria connected to each other by a transmission line, 
wherein the cafeteria server is provided with a menu file 
for storing information concerning the menu provided by 
the cafeteria, an ingredient file for storing names of 



ingredients and quantities which become necessary for 
every item on the menu stored in the menu file, a 
reception file for storing information concerning the 
items on the menu ordered by the user, an ingredient 
totaling. file for totaling the quantity which will become 
necessary for every ingredient based on the order by the 
user, and a serving file for storing information 
concerning the items of the menu which have to be cooked 
during a certain period, the quantities thereof, and the 
ingredients required for cooking the items of the menu 
therein. 

In the cafeteria server, information concerning 
suppliers for every ingredient may be stored in the 
ingredient totaling file. 

The cafeteria server may be connected to a terminal 
provided at a supplier by a transmission line; terminal 
identification information of the supplier may be stored 
in the ingredient totaling file; and order information 
may be transmitted to the supplier terminal over the 
transmission line according to terminal identification 
information at the time of the cafeteria server ordering 
ingredients . 

Further, in the cafeteria server, a deadline for 
accepting orders from users may be set and the 
ingredients ordered based on the information of the 
ingredient totaling file after the deadline is reached. 

Information concerning the names of the items on the 
menu ordered by users and the quantities of the same, 
utilization time, method of payment, and special requests 
may be stored in the reception file. 

Information concerning the quantities of items on 
the menu already prepared may be stored in the serving 
file. 

The quantity of uncooked food may be calculated 
based on the quantities of items on the menu already 
prepared and the quantity of uncooked food displayed on a 
screen. 
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Information concerning the quantity of uncooked food 
may be stored in the serving file for every item on the 
menu. 

A flag for indicating whether supplies have been 
delivered for every ingredient may be set in the serving 
file. 

A flag for indicating whether supplies have been 
delivered for every ingredient may be set in the 
ingredient totaling file. 

Photo information may be stored for every item on 
the menu in the menu file. 

An embodiment of a second aspect of the present invention can 
provide a data processing unit installs} in a cafeteria, provided with a 
menu file for storing information concerning the menu 
provided by the cafeteria, an ingredient file for storing 
names of ingredients and quantities which become 
necessary for every item on the menu stored in the menu 
file, a reception file for storing information concerning 
the items on the menu ordered by a user, an ingredient 
totaling file for totaling the quantity which will become 
necessary for every ingredient based on the order by the 
user, and a serving file for storing information 
concerning the items of the menu which have to be cooked 
during a certain period, the quantities thereof, and the 
ingredients required for cooking the items of the menu 
therein. 

The data processing unit may be connected to an 
order terminal from which a user inputs content of his or 
her order and the order of the user accepted in 
accordance with the operation of the order terminal. 

An embodiment of a third aspect of the present invention can 
provide .. .an. :ordering ^system for. receiving an order from a customer, 

provided with a terminal for a customer to input the 
content of an order and a. server for receiving an order 
input from the terminal, the server provided with a 
product file for storing information concerning the 
products which can be ordered by a customer and an order 
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file for storing the content of orders including products 
selected by a customer. 

The server may be further provided, in the ordering 
system, with an order file in which information 
5 concerning products and suppliers for every product are 
stored. 

The server may in addition be provided, in the 
ordering system, with a file in which an inspection flag 
is set for indicating whether or not a product ordered to 

10 a supplier is delivered. 

The order file may store the content of special 
requests made by a customer. 

An embodiment of a_ fourth aspect of the present invention can 
provide an ordering method in an ordering system for receiving an order from 

15 a customer, comprising displaying information concerning 
products which can be ordered on an order terminal and 
updating the content of the order file storing the 
information concerning the content of the orders provided 
in a reception terminal in accordance with the selection 

20 of a product from the order terminal. 

An embodiment of a fifth aspect of the present invention can 
provide an ordering method in an ordering system for receiving an 
order from a customer, comprising displaying a screen of 
a list of products which can be ordered on an order 

25 terminal from which a customer inputs the content of an 

order, displaying a screen of an order form for inputting 
the content of an order on the order terminal in 
accordance with the selection of a product by the 
customer; displaying a confirmation screen for allowing a 

3 0 customer to confirm the content of an order by the order 
terminal in response to the input of the content of the 
order from the order form screen; and accepting the order 
after an operation by the customer confirming the content 
displayed on the confirmation screen. 

35 When displaying a list of products, it may first 

display a screen of a list of large classifications of 
products which can be ordered by the customer and then 



display a screen of a list of small classifications of 
products belonging to a large classification of products 
selected from the screen of the list of large 
classifications by the customer. 

An errbodiment of a sixth aspect of the present invention can 
provide an' ordering system for receiving an order for a product frcm a 

customer from an order terminal, comprising judging, when 
an order from a customer has been input, if the deadline 
for receiving the order has passed or not, accepting, 
when the deadline has not passed, the order from the 
customer, while displaying, when the deadline has passed, 
a message indicating that the deadline has passed on the 
order terminal and not accepting the order. 

Turning now to specific examples of the present 
invention, Fig. 1 is a view of the system configuration 
of a cafeteria system in an embodiment of the present 
invention. Here, particularly, an example of application 
to an employee cafeteria will be explained, but the 
present invention can naturally also be applied to other 
types of restaurants and needless to say can be used for 
various types of ordering systems such as mail order, 
telephone shopping, and on-line sales. 

The cafeteria system according to the present 
embodiment is, roughly speaking, provided with a 
cafeteria server, a cafeteria terminal, at least one 
terminal provided on a customer (that is, employee) side, 
and an employee server. The cafeteria server, terminal 
server, and employee server are connected to each other 
by a network. The employee server is provided with an 
employee data base (DB) and a salary data base. When 
paying a bill by deduction from one's salary when using 
the employee cafeteria, the sum corresponding to the bill 
is deducted from a salary account recorded in the 
employee server. 

Here, a LAN etc. may be utilized in the case of an 
employee cafeteria etc., but in the case of a general 
cafeteria where use by a large number of unknown 
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customers is expected, the recently popularized Internet 
etc. may be used. 

Figure 2 is a view showing the configuration of the 
cafeteria side in further detail. In the example of Fig. 
5 2, the cafeteria side is provided with the cafeteria 

server, a kitchen terminal, an order management terminal, 
a reception terminal, and a counter terminal. Note that 
the terminals on the cafeteria side are not limited to 
these. It is possible to provide other terminals or to 

10 combine the functions of the terminals illustrated in 
Fig. 2 into one terminal. The configuration of the 
cafeteria side can be appropriately changed according to 
the size etc. of the cafeteria. 

A variety of files are provided in the cafeteria 

15 server. Below, an explanation will be made of these 
files . 

Figure 3 is a view for explaining the configuration 
of the menu file. (A) of Fig. 3 is a large classification 
file; and (B) of Fig. 3 is a small classification file. 
20 Information concerning the menu which can be 

provided by the cafeteria are stored in the menu file. 
This menu file is referred to when a customer places an 
order . 

The large classification file stores the large 
25 classes of the content of the menu which can be provided 
by the cafeteria. In the example of (A) of Fig. 3, the 
items "western food, "Japanese food", "Chinese food", 
"bowl meals", etc. are set. 

The small classification file illustrated in (B) of 
30 Fig. 3 is comprised so as to be linked to the large 

classification file. The small classification file stores 
information concerning the names of items on the menu, 
prices, and calories as a set for every large 
classification. In the case of (B) of Fig. 3, the small 
35 classification file for "BOWL MEALS" , the destination of 
the link when " BOWL MEALS " is selected in the large 
classification file, is illustrated. 
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Further, the menu file, although details are not 
illustrated in Fig. 3, also stores a photo for every item 
on the menu linked to every item on the menu in the small 
classification file. The photos of the items on the menu 
5 are displayed at the customer terminal and. used for 
visually checking the content of the menu. 

Figure 4 is a view explaining the configuration of 
the ingredient file. The ingredient file stores sets of 
names of ingredients required for cooking a dish and the 
10 quantities thereof for each item on the menu. 

For example, the Japanese dish "pork cutlet on rice" 
is shown as an example in Fig. 4. Here, information such 
as 180 cc of rice, 100 g of pork, 1/4 of an onion, and 
one egg is stored. This shows the ingredients necessary 
15 for preparing one serving of "pork cutlet on rice" and 

the quantities thereof. Further, in the case of a request 
for a "large serving", information is set indicating to 
increase the ingredients by 10% (not illustrated). 

Such option information such as the increased 
2 0 quantities for a "large serving" may be set for every 

item on the menu in the ingredient file (recorded as "198 
cc of rice" or "increase by 10%"). For example, when 
"large serving" is selected, it is also possible to 
uniformly and automatically increase the quantities in 

2 5 the ingredient file. In the former case, the increased 

quantities must be stored in the ingredient file, while 
in the latter case, it is sufficient to set just the 
normal quantities, but necessary to calculate the 
increased quantities. 

3 0 Further, in the former case, it is also possible to 

change the quantities for the large servings for every 
item on the menu or for every ingredient. For example, it 
is also possible to set the quantities so as to only 
increase the amount of rice by 10 percent and not 
35 increase the other ingredients. Further, when there is an 
item on the menu which cannot be provided as a large 
serving, it is also possible to add information that 



"large serving not possible" to the menu file, and thus 
enabling a provision of user-friendly services. As 
opposed to this, in the latter case, since the structure 
of the ingredient file becomes simple, it may be said to 
be suited particularly for a case where there is not 
enough money on the cafeteria server side and so on. 

Figure 5 is a view for explaining the configuration 
of the order receiving file. In the order receiving file, 
information for identifying the customer (employee number 
in Fig. 5 since an employee cafeteria is used as an 
example), date of utilization, ordered food and the 
quantities thereof, options (special request such as 
large serving) and the quantities thereof, and the method 
of payment are stored. 

Here, if dealing with an employee cafeteria, 
basically the bill may be paid by deducting the amount 
from the salary. Even in the case of an employee 
cafeteria, there is a possibility that an outside person 
will visit it to eat. Since the bill cannot be deducted 
from salary for such a person, it is necessary to make it 
possible to deal with the bill by payment by cash, a 
prepaid card, ic card (electronic money), or the like. 
Further, there may also be employees who choose not to 
deduct the b.ill from their salaries when using the 
cafeteria. In the order receiving file illustrated in 
Fig. 5, the information concerning the method of payment 
is stored together with the content of an order so as to 
enable the order to be handled. 

The method of payment is designated at the time of 
placing the order. Details of this method of designation 
will be explained later. Note that, as the method of 
payment, other than this, payment by a credit card is 
also possible. 

Further, envisioning a case of a members-only store, 
the names of the customers are registered at the store 
side in advance. This resembles the relationship between 
employees and the cafeteria in the case of the example of 
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the employee cafeteria. In this way, when the people who 
come to the store can be specified (in other words, when 
it is not necessary to consider the arrival of walk-in 
customers), it is also possible to uniformly set the 
5 method of payment for every customer. When the customers 
can be specified and also the method of payment can be 
specified, it is also possible to eliminate the 
information setting field concerning the method of 
payment from the order reception file. 

10 Figure 6 is an ingredient ordering file which is 

utilized when the cafeteria orders ingredients. In this 
ingredient ordering file, information concerning the 
ingredients which are to be ordered by the cafeteria, the 
quantities of the order, and the suppliers are stored 

15 without relation with the menu. 

Details of the method, of updating the content of the 
ingredient ordering file will be explained later, but 
briefly the quantities of ingredients are successively 
updated by referring to the quantities of the items on 

2 0 the menu ordered, which are stored in the order receiving 

file, and the quantities of every ingredient for each 
item on the menu required, which are stored in the 
ingredient file. The cafeteria side then places orders 
for the quantities stored in the ingredient ordering file 

25 to the suppliers. 

Here, when for example ordering onions, it is 
probably impossible to order less than one onion. In this 
case, when a fraction arises in the quantity of an 
ingredient stored in the ingredient ordering file, that 

30 fraction is automatically rounded up to a regular unit 

quantity. In the example of an onion, where the required 
number of onions, calculated based on the number of 
orders and the required quantities stored in the 
ingredient file, becomes a fraction less than one, the 

3 5 totaled up quantity is automatically rounded up to reach 

one . 

Further, as the supplier information, in the case of 
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Fig. 6, the names of suppliers are recorded. Here, when 
the suppliers have also terminals connected by a network, 
it is possible to utilize these terminals. For this 
reason, to deal with this, it is also possible to store 
5 the e-mail address etc. for every supplier, refer to 

these at the time of placing orders, and automatically 
transmit the order information to the suppliers via the 
network. Of course, not all suppliers will be connected 
by the network, so in this case the telephone or 

10 facsimile numbers etc. may be recorded together with the 
names of the suppliers. 

Further, in the field "date of delivery", the 
scheduled date when ordered ingredients will be delivered 
is set. This "date of delivery" information can also be 

15 used for checking of whether or not the ingredients were 
delivered. That is, on the date when the ingredients are 
supposed to be delivered, the information for the 
ingredients (names of ingredients) which are scheduled to 
be delivered during that day is read by referring to the 

2 0 ingredient ordering file. Then, it is confirmed whether 
or not the delivery is made for every ingredient. 

Figure 7 shows the serving file. This stores the 
required quantities for the items on the menu which must 
be cooked in a certain day (January 13 in the illustrated 

25 example) and the ingredients which are required for 

cooking them and the quantities thereof in correspondence 
with each other. Further, the serving file may be set 
with the dates of delivery (scheduled dates) of 
ingredients and check flags for indicating whether or not 

30 the ingredients were actually delivered. Note that it is 
also possible to store the dates of delivery and the 
check flags in different files, and alternatively, set 
only one since the contents of the ingredient ordering 
file and the serving file partially overlapped. 

35 The information stored in the serving file is sent 

to the kitchen terminal and the counter terminal where 
the information required for cooking is displayed on 



their screens. When taking a kitchen as an example, the 
items on the menu which must be cooked that day, the 
quantities thereof, the quantities of ingredients, etc. 
can be displayed on the kitchen terminal. Due to this, it 
is possible to confirm at a glance what and how much is 
to be cooked at the time of cooking. Further, a field in 
which the quantities of already prepared foods for use 
that day also are entered is set in the serving file. 
This field is used for the kitchen obtaining an 
information of the quantities which have been already 
cooked or how much must be cooked. 

Depending on the item on the menu, there is a 
possibility that the entire ordered quantity cannot be 
cooked at one time. Therefore, at this time, the item 
must be cooked divided into several portions. At this 
time, it is very effective in running the cafeteria if 
information on how many servings have been already cooked 
or how many servings still have to be cooked are 
displayed on the kitchen terminal. Therefore, the serving 
file stores the above information and the kitchen 
terminal displays the number of the already cooked 
servings or the number of the uncooked servings when 
displaying the information. 

Further, when there is a special request (option) 
such as a request for a large serving, this information 
is also set in the serving file. Although not illustrated 
in Fig. 7, the quantities of the large servings and other 
options may be written in the serving file separately 
from the overall required quantity of food (inclusive 
number also possible). Due to this, it is possible to 
display, on the kitchen terminal, what and how many 
options should be cooked for easy understanding and 
reduce the errors in cooking or the like. 

Figure 8 shows an individual setting file. In the 
example of Fig. 8, an employee number and password are 
set in pairs for every customer. These are used for 
comparison against a password which is input when a 
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customer places an order and are designed not to be able 
to be seen by a usual operation. 

In the case of Fig. 8, a case where the method of 
payment is not specified for every customer is assumed. 
5 However, -there is also a case where the method of payment 
can be specified if the customer can be specified as in a 
members-only store as explained above. In this case, a 
field for recording the method of payment is set in the 
individual setting file. Further, in a case where the 

10 method of payment becomes uniform irrespective of the 
customer as in the case where only payment by cash is 
accepted, it is possible to not set information 
concerning the method of payment in any file. 

In the present embodiment, these files are set in 

15 the cafeteria server. Note that a modification in which 
the contents of the files illustrated in the figures are 
combined in one file is also possible. 

Figure 9 is a view of an example of the 
configuration of the terminal side. In recent years, 

20 personal computers are being installed in the workplace 
. in increasing cases. Therefore, these usual personal 
computers etc. can also be used as the terminals. 
Further, of course, it is also possible to utilize 
exclusive terminals for placing orders. Here, personal 

25 computers are almost always provided with printers. 

Further, they can also be connected to IC card readers or 
writers (illustrated as R/W, same below). When a customer 
places an order, these printers and R/Ws may also be 
used. 

30 When a customer places an order, a meal ticket may 

be issued by using a printer installed at the customer's 
workplace. By using a usual printer, there is no need to 
go to the trouble of providing a special new printer for 
the meal tickets (though installing them may also be 

35 possible) . 

Further, in recent years, as proof of employment, ID 
cards (magnetic cards or IC cards) have been used. 
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Therefore, use of such cards at the time of utilization 
of the cafeteria can be considered. Particularly, an ic 
card has a large storage capacity, therefore if the 
content of the orders is written in the IC card in place 
5 of the meal ticket, it is not necessary to print a meal 
ticket by using a printer. 

Figure 10 is a block diagram of the configuration of 
the internal portion of a terminal. The terminal is 
provided with a CPU for performing the processing, a 

10 communication control unit used when communicating with 
the network, a memory in which various types of programs 
are stored and also the content input at the time of 
ordering is temporarily stored, a display, a printer, a 
keyboard for inputting the information, and a card R/w. 

15 Figure 11 is a view of the configuration of the 

reception terminal/management terminal on the cafeteria 
side. An ordinary personal computer can be used for this 
terminal as well. This terminal has a similar 
configuration to that of the terminal illustrated in Fig. 

20 10. in the case of Fig. 11, the illustration of the 
printer and R/w is omitted. This is because only the 
minimum configuration for realizing the functions 
indispensable for the present embodiment is illustrated. 
Of course, these devices can be provided according to 

25 need. 

Figure 12 is a view of the configuration of the 
counter terminal installed at every counter of the 
cafeteria. The counter terminal can be a general personal 
computer or the like or can be an exclusive terminal 

30 considering the convenience to the user taking into 

account that the customer has to operate the terminal 
when coming to the cafeteria. 

The counter terminal is provided with a display or 
card R/W. The ID card of the employee may inserted into 

35 the card R/W. When the content ordered by the employee is 
written into his ID card, information concerning the 
items on the menu ordered by that customer (information 
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such as the names of the items on the menu, quantity, and 
location) are displayed on the display in accordance with 
the content of the order read from the IC card. 
Alternatively, it is possible for the counter terminal to 
5 refer to^the cafeteria server, read the content of an 
order of an employee who inserted the ID card into the 
card R/W, and display the same on the display. When only 
the employee number or the like is recorded on the ID 
card, it is also possible to read this from the R/W, 

10 refer to the cafeteria server, and display the 

information on the items on the menu ordered by that 
customer. The form of this can be appropriately 
determined in accordance with the method of operation of 
the cafeteria. Needless to say, other methods can be 

15 applied as well. The customer receives the items on the 
menu which he ordered in advance according to guide 
information displayed on the display of the counter 
terminal. 

Note that it is also possible to give the counter 
20 terminal the function of issuing a meal ticket. The 

printer illustrated by the dotted line in Fig. 12 is used 
for issuing the meal ticket. When inserting an ID card 
into the card R/W, the stored order information is read 
and the meal ticket is issued from the printer based on 
25 this. 

Figure 13 is a view of the configuration of the 
kitchen terminal. When considering only the purpose 
explained heretofore, it is sufficient so far as the 
content to be cooked be displayed on the kitchen 

30 terminal, therefore, in the case of the present 

embodiment, a printer for a card R/W or issuing a meal 
ticket is not particularly necessary (these may become 
necessary for other purposes). For this reason, a card 
R/W and printer are not particularly illustrated in the 

35 kitchen terminal according to the present embodiment. 

Figure 14 is a flow chart illustrating the routine 
when noting the operation of the user mainly where it 



places an order using the cafeteria system. 

First, when using a cafeteria system, the user 
accesses the cafeteria server ("cafeteria home page" in 
the figure) from a terminal disposed in its office. Here, 
5 the reason why the term "home page" is used in the 

illustration is that consideration is given to increasing 
utilization of the Internet in coming years. 

When the cafeteria server is accessed, the screen 
information for selection of the menu is transmitted from 

10 the cafeteria server to the terminal. The terminal 

displays the received screen information on its screen. 
The user selects the items on the menu which he or she 
desires to order from that screen. Then, the selected 
order information is sent to the cafeteria server. The 

15 cafeteria server prepares an order form screen based on 
the information sent from the terminal and transfers its 
screen information to the terminal. At the terminal, the 
transferred order form screen is displayed on its display 
and the order form input by the user is awaited. The 

20 order form is used for confirming the content of the 
input order. Details of the order form screen will be 
explained later. 

The user inputs the content of an order from the 
order form screen. When the input of the order form is 

25 confirmed, a confirmation screen is displayed on the 

terminal in response. Using this confirmation screen, the 
user can confirm if the content of an order was correctly 
input or confirm if his or her order should be settled. 
After checking the content of an order, the user 

30 executes a confirmation operation. On the other hand, 

when changing the content of an order, the order screen 
is displayed again and the order is input again. 

Figure 15 explains the operation in the case of 
issuing a coupon (meal ticket) using a printer equipped 

35 in the terminal after the operation of Fig. 14. When the 
confirmation operation is executed, the input content of 
an order is transmitted to the cafeteria server as 



confirmed, in response to this, the cafeteria server 
sends information which is necessary for issuance of the 
coupon to the terminal. The terminal edits the 
information for issuing the coupon after receiving it and 
activates the printer to issue the coupon. 

Figure 16 shows the processing, in place of the 
processing of Fig. 15, in the case where the content of 
an order is written in a card (IC card etc.) held by the 
user. The processing is similar to the case of Fig. 15 U p 
to the point where the confirmation operation is carried 
out in Fig. 14 and the order confirmation is transferred 
to the cafeteria server. Then, in the same way as the 
case of the issuance of a coupon, information concerning 
the ordered food is sent from the cafeteria server to the 
terminal. Note that the information at the time of 
issuance of the coupon and the information written on the 
card may be exactly the same. This is because it may be 
considered that the information of a coupon usually 
printed as paper is written in the IC card instead. Of 
course, it is also possible to prepare information 
separately for each of the formats such as the coupons or 
cards described above. 

When the terminal receives information from the 
cafeteria server, it displays a message prompting the 
insertion of the card into the card R/W to the user. When 
the user inserts the card into the card R/W along with 
this, the terminal writes the information concerning the 
content of the order in the card inserted and then ejects 
the card. 

The series of processing for placing an order is 
executed by such a processing operation. Details of the 
routines will be explained later according to need. 

Figures 17A and 17B and Fig. 18 are flow charts for 
explaining details of the series of operations at the 
terminal and cafeteria side at the time of placing an 
order. The left sides of the figures show the processing 
on the terminal side, while the right sides of the 



figures show the processing on the cafeteria server side. 

On the terminal side, first, the cafeteria server is 
accessed. In response to this, the cafeteria server 
transfers the initial screen data to the terminal. The 
terminal, displays the initial menu on the screen based on 
the received initial screen data. 

Figure 19 is a view of the example of the initial 
menu screen. The initial menu screen displays large 
classes of items of the menu which can be selected by the 
user and items for setting a PIN code {details explained 
later). The user first selects a large class of items on 
the menu to be ordered by using the initial menu screen. 

When a large class of items on the menu is selected 
from the initial menu, the result is notified to the 
cafeteria server. The cafeteria server refers to the menu 
file, reads the small classification information 
corresponding to the selected large class, and transfers 
the same to the terminal. On the terminal, the 
transferred small classification information is displayed 
on the screen. Here, a list of the items on the menu is 
first displayed. 

Figure 2 0 illustrates an example of the list of the 
selection of items on the menu when a Japanese food menu 
.is selected from the screen illustrated in Fig. 19. in 
the menu list, names of items on the menu which can be 
provided by the cafeteria, prices thereof, and calories 
are displayed in the form of a table, when a user selects 
a specific item on the menu from the menu screen, the 
detailed menu is displayed on the screen of the terminal. 

Figure 21 illustrates an example of the display of 
the screen of the detailed menu and shows an example of a 
case where a grilled fish set is selected. The detailed 
menu screen displays the content (item) of the selected 
menu and a photo of the item. By this, the user can 
confirm the content of the item on the menu which he or 
she is selecting. Note that, on the detailed menu screen 
illustrated in Fig. 21, it is explained that a larger 



serving of rice costs an extra 20 yen. By this, the user 
can be informed that a large serving can be obtained in 
the grilled fish set. 

Further, at the right corner of the detailed menu 
5 screen, an "order" field and a "return" field are set. 

When the "order" field is selected, the order of the item 
on the menu displayed on the detailed menu screen is 
transferred to the cafeteria server side. Further, when 
the "return" field is selected, the screen changes to the 

10 selection menu screen again. 

Upon receipt of the selection of the "order" field 
on the detailed menu side, the cafeteria server edits the 
screen of the order form in accordance with the selected 
item on the menu and transfers this to the terminal. 

15 Figure 2 2 is a view of an example of the order form 

which is displayed on the screen of the terminal 
receiving the information from the cafeteria server. The 
order form automatically displays the date of the order. 
Further, the order form is set with employee number input 

20 field, an order display field, an order quantity display 
field, an option information selection field, an option 
object number display field, a utilization date display 
field, a payment method display field, and a PIN code 
input field. 

25 The employee number is input in the employee number 

input field manually by the user or by reading the ID 
card. The order display field displays the name of the 
item on the menu selected on the detailed menu screen. 
The option information selection field is used for 

30 selecting information concerning various options (special 
requests) such as a "large serving of rice". The content 
of the options is determined in accordance with the 
selected item on the menu. The user appropriately selects 
the intended content from this . 

35 There are many foods which cannot be eaten or are 

not eaten due to the preferences of the individual or his 
or her constitution or health. The option selection 
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according to the present embodiment can also handle such 
cases. That is, by inputting items which he or she cannot 
eat from the option information selection field, specific 
items can be removed from the ordered menu. In the 
5 example of the "grilled fish set", it becomes possible to 
omit for example a "vegetable salad" or eliminate 
specific items in the "vegetable salad". 

Further, if the cafeteria side can handle it, as a 
further option, it is also possible for a user to 
10 designate the addition of an item which is not indicated 
on the menu. 

In the display field of the utilization date, since 
this embodiment basically considers the orders for the 
next day, the lunch time hours of the next day are 

15 automatically displayed. Note that the user does not 

always place orders only for the next day and there are 
cases where he or she cannot come to the cafeteria at 
lunch time. For this reason, in the present embodiment, 
it is made possible to change the date of utilization by 

20 manually inputting the date from the field of the 
utilization date. 

If the utilization date, particularly the time, is 
designated in advance, the cafeteria side may cook the 
food to be ready for the time. For this reason, the input 

2 5 of the utilization date from the confirmation screen is 
very useful for the cafeteria side. 

Since the example of the employee cafeteria is taken 
into account in the present embodiment, "salary 
deduction" is automatically displayed in the field of the 

30 method of payment. Note that not all of the users who 

visit the employee cafeteria are always employees of the 
company, so the selection of a method of payment other 
than salary deduction must also be made possible. For 
this reason, when another method of payment (cash 

35 payment, utilization of card, etc.) is selected, the 

intended method of payment is selected in the field of 
the method of payment. 
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In the utilization of the cafeteria system, monetary 
transactions take place, so in the present embodiment, it 
is judged if the user is the proper person by having him 
or her input a PIN code. The input PIN code is verified 
5 on the cafeteria server side as well as the employee 
number to decide whether or not the input code is 
correct. 

When the input of this information is confirmed, the 
order form is transferred to the cafeteria server, 

10 therefore, in response to this, the screen information of 
the order reception confirmation is transferred from the 
cafeteria server to the terminal and displayed on the 
terminal. Figure 2 3 is a view of one example of the 
screen of the order reception confirmation. 

15 On the screen of the order reception confirmation, 

various items such as the time of ordering, utilization 
date, ordered item and quantity, the content of options 
if any, the bill, and method of payment are displayed. 
The user refers to the screen of the order reception 

20 confirmation to confirm whether or not the content of 
one's order was correctly input. 

At the right corner of the screen of the order 
reception confirmation, a "confirm" field and "cancel" 
field are set. when the content of an order is correct or 

25 is not changed, the "confirm" field is selected. By this, 
the content of an order is confirmed and this is notified 
to the cafeteria server. When the "cancel" field is 
selected, the previous screen (selection screen etc.) is 
displayed. 

30 When "confirm" is selected, the cafeteria server 

deems that the order has been confirmed and updates the 
contents of the files such as the ordering file, already 
explained in detail, based on the input content of an 
order. 

35 This ends the series of processing for placing an 

order. 

Figure 24 is a flow chart illustrating the 



processing at the terminal in the case of considering 
entry of a PIN code (password), when the cafeteria server 
is accessed and the initial menu is displayed, the 
terminal determines whether or not entry of a password 
was selected (monitoring whether not a selection of item 
was made), when entry of a password is not selected, it 
is determined by the monitoring whether or not the menu 
(large classification) was selected. 

Here, when entry of a password is selected, the 
terminal executes the processing of Figs. 25A and 25B. 

Figures 25A and 25B are flow charts illustrating the 
series of processing for setting a password. Further, 
Fig. 26 illustrates the initial screen of the password 
entry. Here, the password entry includes new entry and 
change of password, so the user select which to carry out 
by using the initial screen illustrated in Figs. 25A and 
25B. 

First, an explanation will be made of the case of 
new entry. This is executed in a case where the customer 
newly utilizes the cafeteria system etc. 

When "new entry" is selected from the initial menu 
of the password entry, the screen for new entry of the 
PIN code is displayed on the screen (Fig. 27). On the 
screen for new entry of the PIN code the employee number 
input field and the PIN code input field are set. The 
user inputs the secret code to be entered together with 
his or her employee number by using the screen for new 
entry of a PIN code. Note that, in order to prevent the 
PIN code from being seen by others, in the example of 
Fig. 27, asterisks are displayed instead of the digits of 
the PIN code which are input. 

when the employee number and the PIN code are input 
from the screen for new entry of a pin code, the screen 
for confirmation of the entry of the PIN code is 
subsequently displayed (Fig. 28). Here, by inputting the 
previously input PIN code again, it is confirmed whether 
or not the pin code is correct and therefore the pin code 



was input as intended by the user. 

Here, when the PIN code input from the screen for 
the new entry of a PIN code and the PIN code input from 
the screen for confirming the entry of the PIN code 
5 match, the processing for entry of the PIN code is 

terminated, and the initial menu screen of the Fig. 19 is 
displayed on the terminal. 

On the other hand, when the PIN code was not 
correctly input again, a message informing the user of 
10 the input error of the PIN code such as "Please input 

designated PIN code again" is displayed on the screen to 
prompt the user to input the PIN code again. 

Next, an explanation will be made of the processing 
at the time of change of the PIN code. 
15 when "change code" is selected on the screen for 

entry of a PIN code, the terminal displays the screen for 
change of a PIN code (Fig. 29). When this screen is 
displayed, the user inputs the PIN code at that point of 
time together with its employee number. Due to this 
20 processing, the legitimacy of the person desiring to 
change the PIN code is confirmed. 

when the current PIN code is correct, a new PIN code 
is input from the new PIN code input field (Fig. 30). 
Then, in the same way as the case of a new entry, the 
25 screen for the confirmation of the entry of the PIN code 
illustrated in Fig. 28 is displayed on the terminal. 

When the PIN code is entered, this information is 
transferred to the cafeteria server side. Then, it is 
stored in the individual information file linked with the 
30 employee number. 

The initial menu is displayed again after the entry 
of the PIN code, so the user desiring to place an order 
next can select an item from the menu in the same way as 
at the time of placing a usual order. 
35 Here, if making it possible to input a name, 

address, etc. in place of the employee number, the 
processing of Figs. 25A and 25B can be applied for 
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registration for use at general cafeterias. At this time, 
as one choice of the method of payment, there is payment 
by a credit card. When it is hard to identify customers, 
unlike in an employee cafeteria, it is also useful to 
5 request the input of a credit card number etc. and check 
if there will be a problem in the customer's ability to 
pay. 

Figure 31 is a flow chart of the processing routine 
on the cafeteria server side after an order is received. 

10 When an order is transferred from the user, the cafeteria 
server first writes the employee number, date when he or 
she came, ordered item on the menu, quantity, and 
information of options if any in the order reception 
file. Then, the cafeteria server refers to the ingredient 

15 file corresponding to the ordered item on the menu. 

When the ingredient file is referred to, the 
cafeteria server next reads the ingredients corresponding 
to the ordered item and the quantities from the 
ingredient file and updates the ingredient file based on 

20 this. In this, it adds to the quantities for every 

ingredient stored in the ingredient file the quantities 
corresponding to the number of items on the menu newly 
ordered. Here, as previously explained, the ingredient 
file is used for the. ordering of the ingredients, 

25 therefore where the quantity is less than the unit 

number, a totaled up quantity rounded up to reach the 
unit number is recorded in the quantity field. 

Next, based on the transferred order, the content of 
the serving file is updated. The serving file records the 

3 0 quantities of the items on the menu (including 

ingredients) which have to be cooked on a certain day for 
every item on the menu. When a new order is placed, the 
quantities in the serving file are updated. Similarly, 
the quantities of the ingredients for every item on the 

3 5 menu are updated. 

In the cafeteria system according to the present 
embodiment, a deadline for acceptance is set for the 



convenience in ordering the ingredients. Figure 32 is a 
view of the processing at the cafeteria server in the 
case of an order from a terminal. Here, when the terminal 
is operated for making a selection of an item on the 
5 menu, it; is determined whether or not the deadline has 
passed. When the deadline has not passed, the order is 
accepted, but when the deadline has passed, the order 
cannot be accepted. 

Further, in order to order the ingredients so as to 

10 be in time for cooking on a certain day, for example, it 
is necessary to order the ingredients from the suppliers 
in the afternoon of the previous day at the latest. 
Therefore, when the deadline has been reached, the 
cafeteria server side reads the content of the ingredient 

15 file and orders the ingredients recorded there from the 
suppliers . 

Sometimes a user will want to change the content of 
or cancel an order he or she placed once. In this case as 
well, the cafeteria system according to the present 

20 embodiment can handle this if before the deadline. 

Figures 33A and 33B are flow charts for explaining the 
processing routines for this purpose. 

when canceling an order, the user accesses the 
cafeteria server and. selects the cancellation screen (not 

25 particularly illustrated). Then, the cafeteria server 
determines whether or not the canceling operation has 
been performed after the deadline, when the deadline has 
passed, there is a possibility that the ingredients have 
already been ordered, therefore the cafeteria server 

30 cannot accept the cancellation (change) of the order. For 
this reason, the terminal is instructed to display a 
screen notifying the user of the fact that the 
cancellation operation was after the deadline. 
Simultaneously, it notifies the user of the fact that 

35 there is a cancellation fee for cancellation. 

Next, the cafeteria server instructs the terminal to 
display a screen for confirming the possibility of 



cancellation. When cancellation is impossible, the order 
is not canceled and the processing is terminated. On the 
other hand, when the terminal is operated for instructing 
cancellation, the cancellation is processed. 

Note that there may also be cases where the 
cancellation fee is not paid even though of the 
cancellation was made after the deadline. This is 
particularly a problem when payment was made at that 
time, for example, by cash. Accordingly, if an order is 
canceled after the deadline, it is necessary to confirm 
whether or not the cancellation fee was paid. It may 
therefore become necessary to limit use of the cafeteria 
system for customers who frequently cancel orders after 
deadlines and do not pay the cancellation fees. 

Further, the cancellation may be processed even if 
the cancellation operation is made before the deadline. 

Where the cancellation is processed, the cafeteria 
server side refers to the reception file and reads the 
order of the related user. The cancellation screen is 
then edited and transferred to the terminal. 

The cancellation screen displays at least the items 
ordered by the related user and the scheduled date of 
utilization date. Note that when the same user places 
orders for a number of days or times, all scheduled dates 
of arrival at the cafeteria of the related user are 
displayed in a list and the user is made to select from 
it. When they will not completely fit on one screen, a 
split display is also possible. 

when the cancellation screen is displayed, the user 
selects the content to be cancelled and executes the 
cancellation operation. After the cancellation operation, 
a screen for confirming the content of the cancellation 
is displayed in the same way as the confirmation screen 
at the time of placing an order, when the cancellation by 
the user is confirmed on the confirmation screen, the 
cafeteria server corrects or updates the content of each 
file in accordance with the content of the cancellation. 



Note that, of course, in the cancellation 
processing, it is possible not only to cancel the entire 
content of an order for a certain date, but also to 
cancel only part. For example, this is the case where it 
5 is necessary to cancel only one item out of a plurality 
of items ordered for the same day. 

Further, a change of an order is processed by a 
similar procedure. In this case, in place of the 
cancellation, the content of the change is written in 

10 each file. 

Figure 34 is a flow chart illustrating the routine 
for processing using the kitchen terminal. The kitchen 
terminal can display the items on the menu which must be 
cooked at that day and the quantities thereof. Figure 34 

15 shows the routine for this purpose. 

Figure 35 illustrates an example of the screen 
displayed on the kitchen terminal. In the example of Fig. 
35, the items on the menu which must be cooked that day 
and the quantities thereof are displayed together. In 

20 order to display the details, the items to be displayed 
on the screen of Fig. 35 are selected on the kitchen 
terminal. For the selection of items, a keyboard or 
various types of pointing devices can be used. If a touch 
panel is formed on the screen, items can be selected by 

25 just touching the screen. 

Here, an explanation will be made of an example 
where details of the ingredients are displayed for every 
item, when "pork cutlet on rice" is selected on the 
screen of Fig. 35, the ingredients required for cooking 

30 pork cutlet on rice, the required quantities of the 
ingredients for cooking all of the servings, and the 
required quantities of ingredients for cooking one item 
are displayed together (Fig. 36). Further, a reference 
field for options is provided at the right corner of the 

35 screen. Here, information concerning the existence of any 
options and the content thereof and the change of the 
quantities of the ingredients etc. are displayed. Note 
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that, in Fig. 36, an example where the ingredients and 
quantities required for cooking all of the servings and 
the ingredients and quantities per item are displayed is 
illustrated, but as will be explained in detail later, it 
5 is also possible to display the quantities of the 

ingredients required for cooking the remaining quantity 
of uncooked servings in correspondence with the input and 
display of the remaining quantity of uncooked servings. 
When a certain item on the menu is cooked, the 

10 kitchen terminal is used to input that it has been 

cooked. Here, there are also cases where it is difficult 
to simultaneously cook all ordered items as explained 
above, therefore it is made possible to input the 
quantity of the already cooked servings for every item on 

15 the menu. The content of this is reflected in the serving 
file and the quantity of orders in the serving file is 
updated (reduced) by the amount of the already cooked 
servings. The kitchen terminal may be used to confirm if 
all servings have already been cooked or how many 

2 0 servings remain uncooked. 

An information field indicating that all servings 
have finished being cooked is also set in the screen of 
Fig. 35. When the predetermined number of servings of the 
related item on the menu has finished being cooked, a 
25 mark indicating this (a circle in the illustration) is 

added. By this, it can be seen at a glance that it is not 
necessary to cook more grilled fish sets in the case of 
Fig. 35. Note that all of the items on the menu which 
have not yet finished being cooked are not particularly 

3 0 displayed in Fig. 35. In order to display the remaining 

number of uncooked servings, an item on the menu is 
selected by using the kitchen terminal. When using a 
touch panel, the remaining number of uncooked servings of 
a related item on the menu is put on display by touching 
35 the field of finished cooking for the specific item on 
the menu. 

Figure 37 shows an example of display of a screen 



showing the remaining number of uncooked servings of pork 
cutlet on rice. Here, together with the entire remaining 
number of uncooked servings, the remaining number of 
uncooked servings is displayed for each of the options, 
5 including normal servings. By performing such a display, 
every item on the menu can be cooked without waste or 
shortage in the kitchen. 

Note that it is possible to display the remaining 
quantity together with the finished cooking screen of 

10 Fig. 35. In this case, the procedures of switching 
screens can be reduced. Note, if the options are 
displayed on the screen of Fig. 35 together, there is a 
possibility that the screen might be too fine and hard to 
see, therefore the remaining number of uncooked servings 

15 including the options is preferably displayed on a 

different screen. In this case, it may be required to 
display, for example, the remaining number of uncooked 
servings in the "finished cooking" field of Fig. 35. 

Figure 38 shows an example of a screen for checking 

20 the delivery of goods displayed on the kitchen terminal. 
This screen is used for confirming whether or not 
ingredients were actually delivered for every ingredient. 
A circle is added to the ingredients whose delivery was 
confirmed on the screen, when for example there are 

25 reasons for a shortage etc., this is displayed too 
(triangle in the illustration). 

Figure 39 illustrates the part of a keyboard used in 
the kitchen terminal. Function keys for instructing 
specific functions are arranged together with the ten-key 

30 portion. As the function keys, in the illustrated 
example, functions such as "confirm special order 
(option)", "confirm check", "see ingredients", "input 
finished cooking", and "see notes" are set, but they can 
be suitably changed. For example, if the "see 

35 ingredients" function key is pressed, the screen of Fig. 
38 is displayed. 

Figure 40 is a flow chart illustrating the 
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processing and operation routine when a user comes to the 
cafeteria. Here, a case where an ID card is utilized is 
used as an example. 

When the user arrives, he or she inserts his or her 
ID card into the counter terminal. This processing may 
also be performed by manually inputting the employee 
number from the terminal as illustrated. 

By this, the counter terminal refers to the 
cafeteria server and reads the information concerning the 
items on the menu ordered by the related user from the 
reception file and displays them on the counter terminal 
{Fig. 41). in addition, it displays the information 
indicating where he or she can obtain the ordered items. 
This can be handled by storing information in advance in 
the reception file or the menu file, while linking 
counters with every item on the menu. 

Further, it displays information as well for the 
customer who orders an option to confirm that the option 
was ordered. 

Here, the fact that a user, who placed the order 
attaching special conditions such as options, arrived at 
the cafeteria is displayed on the kitchen terminal etc. 
by the insertion of the ID card and the reading of his or 
her id. Due to this, the option such as a large serving 
can be reliably served to the related user. 

When the user receives the ordered item, the number 
of received items is subtracted from the serving file. By 
this, it becomes possible to confirm the remaining 
amounts of the items on the menu at all times. 

When the content of an order is recorded in an IC 
card, it is not necessary to refer to the cafeteria 
server at the time of display of the ordered items. 

Further, for the payment, the method of payment is 
designated in advance at the time of the order. 
Therefore, when the customer utilizes the cafeteria 
terminal, it displays a screen requesting that he or she 
should confirm the method of payment. When the bill will 



- 36 - 



be deducted from the salary or there will otherwise be no 
transfer of cash on the spot, the terminal will display 
"paid" or the like. On the other hand, in a case where 
payment by cash or payment by credit card is selected, 
the terminal displays information for guiding the 
customer to another cash counter for such payment. 

Here, in order to prevent customers from cheating, 
an alarm may be activated or another means adopted when a 
person designating payment by cash does not pay. 

Figure 42 is a flow chart of the processing after 
the check of ingredients. When the ingredients are 
checked, a check flag of the serving file is added in 
accordance with its input. Further, the content of the 
serving is read from the file by instruction from the 
kitchen terminal and displayed on the kitchen terminal. 

Each time an item on the menu is cooked, the cooked 
item and the quantities thereof are input from the 
kitchen terminal to update the quantity etc. in the 
serving file. 

Figure 43 is a view of the example of the screen 
displayed at a terminal when a cafeteria is booked full 
at the designated date and time of utilization as a 
result of orders, which is particularly useful in the 
case of use of the system for a reservation-only 
restaurant. At the bottom of the screen, a confirmation 
field is set. 

Here, since the terminals and the cafeteria server 
are connected by a network, the requests of the users 
etc. can be easily conveyed to the cafeteria side. 
Therefore, it is also possible to make the terminal 
display a questionnaire screen and to ask users to input 
items which they would like to see on the menu in the 
future from the questionnaire screen. 

The cafeteria server totals the answers of the 
questionnaires from users. Due to this, it becomes 
possible to know the preferences of the users and to 
offer a menus tailored to the demands of the users. 



- 37 - 



Heretofore, menus have been determined according to 
past results on the cafeteria side or menus have been 
determined based on the culinary trends in the world. It 
is very difficult to add new items to a menu in the 
5 former case and impossible to provide foods desired by 
the users any longer if the gap between world culinary 
trends in the world and the actual customers of the 
cafeteria becomes too great in the latter case. 

According to the present embodiment, such problems 
10 can be solved and the service provided to the users can 
be improved. 

Note that, in the above embodiment, the explanation 
was made of an example where the same quantities of 
ingredients were ordered and the number of servings 

15 prepared as the number of servings ordered by the 

customers. However, leaving aside restaurants requiring 
reservations, there is also the possibility of walk-in 
customers on the day in question. In such a case, if only 
the reserved servings of food are prepared, a customer 

20 who walks in on that day without a reservation cannot be 
served at the restaurant or will end up eating the food 
intended for others, so there will be a possibility that 
a customer who placed a reservation cannot be served his 
order. 

25 In order to cope with such a case, it may be 

considered to slightly increase the quantities of 
ingredients to be ordered or increase the number of 
servings that day. Specifically, the numbers of servings 
and the quantities of ingredients set in the ingredient 

3 0 ordering file of Fig. 6 and the serving file of Fig. 7 

are recorded slightly increased. That is, the ingredients 
are ordered in slightly larger amounts than the actual 
quantities necessary for preparing the reserved servings 
and larger numbers of servings are prepared. 

35 Here, it is the most reliable for the cafeteria side 

to decide on the amount of increase by experience, but 
when there are no grounds for making such decisions, it 



- 38 - 



is simplest to just increase the quantities uniformly for 
each item on the menu. 

However, such excessive ordering and cooking may 
result in waste. Nevertheless, when compared with a case 
5 of predicting from nothing the quantities of ingredients 
required and the number of servings required - that is, 
from a state where no base figures exist, when the 
ordering system is used to obtain reservations in 
advance, the minimum required quantities can be 

10 determined in advance and therefore the waste in orders 
and cooking can.be reliably reduced. 

Further, in such a case, it is necessary to secure 
the reserved food for the customers who placed 
reservations. For this purpose, it is necessary to 

15 maintain a constant grasp over the number of servings 
which can be provided to customers who did not make 
reservations . 

The number of servings which can be provided to 
customers who did not make reservations corresponds to 

20 the total number of servings prepared minus the number of 
reserved servings. This amount is kept separate from the 
reservations, whenever a customer comes in, it is 
determined by the use of an ID. card or the like whether 
or not this customer is a customer who has already made a 

2 5 reservation. The destination to which the customer is led 

to is varied in accordance with whether or not he had 
made a reservation. 

Customers who made reservations are led to a 
destination for serving customers with reservations. 

3 0 Customers who did not make reservations are led to a 

destination for serving customers without reservations.. 
In both cases, the remaining servings are calculated 
whenever food is served. Particularly, the remaining 
amount of servings for customers who have not made 
3 5 reservations is constantly displayed. Preferably, a 

message indicating "no servings remaining" is displayed 
for the items on the menu which have run out. 



Alternatively, a list of items which can be served and 
the quantities thereof can be displayed so that customer 
without reservations can decide at a glance what is 
available when coming to the restaurant. 

Further, since the ordering system has not confirmed 
the identity of a customer walking in without a 
reservation, it is preferable that the customer be asked 
to indicate the method of payment, for example, cash, and 
to avoid the deduction of the bill from the salary or the 
like to avoid later trouble. 

When an embodiment of an ordering system according to the present 
invention is used, one or more of the following effects can be achieved: 

1) Particularly in the case of a cafeteria or 
restaurant, it can be determined what items on the menu 
have been ordered in what quantities in advance. For this 
reason, the number of servings to prepare and quantities 
of ingredients to order may be determined in accordance 
with those numbers and therefore efficient operation of 
the cafeteria or restaurant becomes possible without 
having to depend upon intuition. 

2) The contents of orders from customers can be 
automatically totaled and updated, so the cafeteria side 
can be saved the troublesome procedure of totaling the 
bills. 

3) Ingredients may be ordered to suppliers 
automatically according to the contents of orders, 
therefore the cafeteria side can prevent errors in orders 
or the like. 

4) Customers can easily place orders by using 
personal computers or the like from offices or the like 
in advance. Since it becomes easy to reserve tables and 
food at restaurants, the customers enjoy greater 
convenience. Further, since the cafeteria side orders 
the ingredients and prepares the servings in accordance 
with. the contents of the orders, the possibility of a 
customer not being able to be served his or her desired 



food becomes very low. 

5) Since the method of payment can be selected 
in accordance with the customer or the circumstance, 
the customers enjoy greater convenience. 

6) Since orders are accepted in advance, the 
ingredients may be ordered and the food cooked 
according to the number of orders. For this reason, 
there is extremely less apprehension of the over 
ordering and wasted cooking of ingredients when 
compared with the conventional case. 

Although embodiments of the present invention as 
described hereinbefore have been for use in a 
cafeteria, it will be appreciated that an ordering 
system embodying the present invention can be used in 
many other situations. For example, the ordering 
system could be used in a computer-aided manufacturing 
(CAM) system in which products such as personal 
computers are manufactured. As is well-known, a range 
of personal computer products may share the same basic 
platform (e.g. casing and motherboard etc), but 
different models within the range will be equipped with 
different optional facilities or modules (e.g. CD Rom 
drive, memory) . In this case, the "menu" would be a 
list of the available models in the range (first file 
of claim 23) . The "ingredient file" (second file) 
would store the identities of the optional modules 
required by each module and the quantities of such 
modules (e.g. random access memory (RAM) modules) . The 
"reception file" (third file) would store a list of the 
modules ordered by each user (for example a 
distributor) . The "ingredient totalling file" (fourth 
file) would store the total quantity of each module 
required to meet the order concerned. The "serving 
file" (fifth file) would store the information 
concerning the models which have to be produced within 



a certain period (e.g. by the end of that day or 
production period, the quantities of those models and 
the modules required to produce the models) . The CAM 
system would use the information in the "serving file" 
to operate automated production facilities. Thus/ an 
embodiment of the present invention can provide a 
manufacturing method employing an ordering system as 
described above. 
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CLAIM5 

1. An ordering system provided with a cafeteria 
server and a terminal operated by a user of the cafeteria 
connected to each other by a transmission line, wherein 

5 the cafeteria server is provided with: 

a menu file for storing information 
concerning the menu provided by the cafeteria, 

an ingredient file for storing names of 
ingredients and quantities which become necessary for 
10 every item on the menu stored in the menu file, 

a reception file for storing information 
concerning the items on the menu ordered by the user from 
said terminal, 

an ingredient totaling file for totaling 
15 the quantity which will become necessary for every 
ingredient based on the order by the user, and 

a serving file for storing information 
concerning the items of the menu which have to be cooked 
during a certain period, the quantities thereof, and the 
20 ingredients required for cooking the items of the menu 
therein. 

2. An ordering system as set forth in claim 1, 
wherein, in said cafeteria server, information concerning 
suppliers for every ingredient is stored in said 

25 ingredient totaling file. 

3. An ordering system as set forth in claim 2, 
wherein: 

said cafeteria server is connected to a 
terminal provided at a supplier by a transmission line; 
30 terminal identification information of the 

supplier is stored in said ingredient totaling file; and 

order information is transmitted to the 
supplier terminal over the transmission line according to 
said terminal identification information at the time of 
35 said cafeteria server ordering ingredients. 

4 . ftn offering system as set forth in ary p^xoing claim, 
wherein a deadline for accepting orders from users is set 



and the ingredients are ordered based on the information 
of the ingredient totaling file after the deadline is 
reached. 



5. An ordering system as set forth in any preceding claim, 
wherein information concerning the names of the items on 
the menu ordered by users and the quantities of the same, 
utilization time, method of payment, and special requests 
is stored in the reception file. 

6. An ordering system as set forth in any preceding claim, 
wherein information concerning the quantities of items on 
the menu already prepared is stored in said serving file. 

7. An ordering system as set forth in claim 6, 
wherein the quantity of uncooked food is calculated based 
on the quantities of items on the menu already prepared 
and the quantity of uncooked food displayed on a screen. 

8. An ordering system as set forth in any preceding claim, 
wherein information concerning the quantity of uncooked 
food is stored in said serving file for every item on the 
menu. 

9. An ordering system as set forth in any preceding claim, 
wherein a flag for indicating whether supplies have been 
delivered for every ingredient is set in said serving 
file. 

10. An ordering system as set forth in any preceding claim, 
wherein a flag for indicating whether supplies have been 
delivered for every ingredient is set in said ingredient 
totaling file. 
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11. An ordering system as set forth in any preceding claim, 
wherein photo information is stored for every item on the 
menu in said menu file. 

12. A data processing unit installed in a 
5 cafeteria, provided with a menu file for storing 

information concerning the menu provided by a cafeteria, 
an ingredient file for storing names of ingredients and 
quantities which become necessary for every item on the 
menu stored in said menu file, a reception file for 

10 storing information concerning the items on the menu 
ordered by a user, an ingredient totaling file for 
totaling the quantity which will become necessary for 
every ingredient based on the order by the user, and a 
serving file for storing information concerning the items 

15 of the menu which have to be cooked during a certain 
period, the quantities thereof, and the ingredients 
required for cooking the items of the menu therein. 

13. A data processing unit as set forth in claim 
12, wherein: 

20 said data processing unit is connected to 

an order terminal from which a user inputs content of his 
or her order and 

the order of the user is accepted in 
accordance with the operation of said order terminal. 
25 14. An ordering system for receiving an order from 

a customer, provided with: 

a terminal for a customer to input the 
content of an order and 

a server for receiving an order input from 

30 said terminal, 

the server provided with: 

a product file for storing information 

concerning the products which can be ordered by a 

customer and 

35 an order file for storing the content of 

orders including products selected by a customer. 

15. An ordering system as set forth in claim 14, 
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wherein said server is further provided with an order 
file in which information concerning products and 
suppliers for every product are stored. 

16. An ordering system as set forth in claim 14 or 15, 
5 wherein said server is further provided with a file in 

which an inspection flag is set for indicating whether or 
not a oroduct ordered to a supplier is delivered. 

17. An ordering system as set forth in any of claims 14 to 16, 
wherein the order file stores the content of special 

10 requests made by a customer. 

18. An ordering method in an ordering system for 
receiving an order from a customer, comprising: 

displaying information concerning products 
which can be ordered on an order terminal and 
15 updating the content of the order file 

storing the information concerning the content of the 
orders provided in a reception terminal in accordance 
with the selection of a product from the order terminal. 

19. An ordering method in an ordering system for 
20 receiving an order from a customer, comprising: 

displaying a screen of a list of products 
which can be ordered on an order terminal from which a 
customer inputs the content of an order, 

displaying a screen of an order form for 

2 5 inputting the content of an order on the order terminal 

in accordance with the selection of a product by the 
customer; 

displaying a confirmation screen for 
allowing a customer to confirm the content of an order by 

3 0 the order terminal in response to the input of the 

content of the order from the order form screen; and 

accepting the order after an operation by 
the customer confirming the content displayed on the 
confirmation screen. 
35 20. An ordering method as set forth in claim 19, 

further comprising, when displaying a list of products: 
first displaying a screen of a list of 



large classifications of products which can be ordered by 
the customer and 

displaying a screen of a list of small 
classifications of products belonging to a large 
classification of products selected from the screen of 
the list of large classifications by the customer. 

21. An ordering system for receiving an order for 
a product from a customer from an order terminal, 
comprising: 

judging, when an order from a customer has 
been input, if the deadline for receiving the order has 
passed or not, 

accepting, when the deadline has not 
passed, the order from the customer, and 

displaying, when the deadline has passed, 
a message indicating that the deadline has passed on the 
order terminal and not accepting the order. 

22. An ordering system for receiving an order for a 
product from a customer comprising: 

a shop server having a menu file for 
storing information concerning products which can be 
served from the shop; and 

a terminal connected with said shop server 
by a network and operated by the customer, thereby 

said shop server is accessed by said 
customer through said terminal to select the product 
stored, as information, in said menu file so that the 
order for the selected product is accepted. 
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23. Ordering apparatus including server means and 
user-operable terminal means connected together by 
transmission line means, wherein said server means is 
provided with: 

5 a first file for storing information 

concerning items available to be ordered; 

a second file for storing first item data and 
second item data associated with each item for which 
information is stored in the first file; 
10 a third file for storing information 

concerning the items ordered by the user from said 
terminal means; 

a fourth file for totalling the second item 
data which will become necessary for every class of 
15 first item data based on the order by the user; and 

a fifth file for storing information 
concerning processing of orders of the available items. 

24. Ordering apparatus as claimed in claim 23, 
for use in a cafeteria, wherein: 

20 the said server means is a cafeteria server; 

the user-operable terminal means are operable 
by a user of the cafeteria; 

the said first file is a menu file and the 
said items available to be ordered are taken from a 
25 menu provided by the cafeteria; 

the said second file is an ingredient file in 
which the first item data specifies names of 
ingredients for each item on the menu and the second 
item data specifies the quantity of the or each 
30 ingredient concerned; 

the third file is a reception file; 
the fourth file is an ingredient totalling 
file for totalling the quantity of each named 
ingredient specified by such first item data in the 
3 5 ■ said second file; and 

the said fifth file is a serving file for 
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storing information concerning the items of the menu 
which have to be cooked during a certain period, the 
quantities thereof and the ingredients required for 
cooking the items of the menu therein. 
5 2 5. 'A computer program which, when loaded into a 

computer system, causes the computer system to become 
an ordering system as claimed in any one of claims 1 to 
11, 14 to 17 and 21 and 22. 

26. A computer program which, when run on a 

10 computer system, causes the computer system to carry- 

out an ordering method as claimed in claim 19 or 20. 

27. A computer program which, when loaded into a 
computer, causes the computer to become a data 

• processing unit as claimed in claim 12 or 13 . 
15 28. An ordering system substantially as 

hereinbefore described with reference to the 
accompanying drawings . 

29. A data processing unit substantially as 
hereinbefore described with reference to the 

2 0 accompanying drawings. 

30. An ordering method substantially as 
hereinbefore described with reference to the 
accompanying drawings. 
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